NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/4439

Internet Message Format | 1996-08-05 | 4.1 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.c
Subject: Re: why not add getch() to the std C RTL?
Date: 4 Feb 1996 08:54:38 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <[e-mail]>,
Bob Nelson <[e-mail]> wrote:
>On Sun, 4 Feb 1996 00:05:32 GMT, John Grant wrote:
>
>> There are *many* people who want to do the following in their C programs:
>> - read a single unbuffered keystroke (getch() in DOS, ioctl in unix...)
>
>> The usual response is "not standard C, o/s-specific" etc.
>
>I'll just quote the following from "Expert C Programming" by Peter van
>der Linden (ISBN 0-13-177429-8) and offer no comments of my own, other
>than some emphasis added.  Instead, it'll be interesting to see how
>participants in comp.lang.c respond to what PvdL thinks (especially in
>the context of your posting). Here's the paragraph from page 213:
>
>"People often wonder why ANSI C didn't define a standard function to
>get a character if a key has been pressed. Without a standard
>function, every system has a different method and program portability
>is lost.  The argument against providing kbhit() as part of the
>standard is that *it is mostly useful for GAMES software* and there
>are many other terminal I/O features that are not standardized. In
>addition, you don't want to promise a standard library function *that
>SOME OS's will find difficult to provide.* The argument for providing
>it is that it is mostly useful for games software and that games
>writers don't need the myriad of other terminal I/O features that
>could be standardized. Whichever view you hold, it's true the XJ311
>missed an opportunity to reinforce C as the language of choice for a
>generation of programmers writings games on UNIX."
>
>Comments?

That's a little bizarre.

I mean, someone isn't going to be discouraged from programming games just
because he or she isn't handed a kbhit() library function on a silver platter.
I don't see how including such a function would reinforce C among UNIX games
programmers (reinforce versus what other popular systems programming language
that DOES provide such a function?)

I'd say that the lack of such a function discourages inexperienced programmers
from writing terminal-based programs altogether, and has little to do with
reinforcing the C language.

It certainly did not stop some good games from being developed (nethack, hunt
and so forth).

Still, a function like kbhit() is simply inappropriate for UNIX. There is more
than One Way (TM) of doing things. You can write games without requiring such a
function. I recently "fixed up" a terminal-based Tetris game which had somewhat
broken terminal interaction.

In my fix, I used completely blocking reads from the "keyboard". The
asynchronous advance of the blocks is triggered by a timer interrupt, so I
never have to check whether or not the keyboard contains a character.

Another way to check is to use non-blocking I/O. A third way is to use a
special terminal input mode that waits for a specified number of cahracters or
a timeout, whicever occurs first. Yet another way is to poll the input file
descriptor (along with possibly others) using select(). All methods require, in
order to detect individual characters, that the terminal be put into cbreak or
fully raw mode first. A kbhit() implementation would have to also include
routines for entering and leaving this raw mode.

Which method of input would kbhit() choose? Non-blocking I/O, special terminal
nput mode, select() or timer interrupts? Each has relative advantages and
disadvantages that depend on the nature of the application and are best left to
the programmer thereof.

In any case, this has strayed from the topic coverage of "comp.lang.c" quite
far already!

But I do hope that it illustrates why some functions are not as easily made
part of portability standard that aims for a very broad scope.
--